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to Symbol Technologies Inc. from the inventors was recorded with the United 
States Patent and Trademark office on 28 September 1998. 

RELATED APPEALS AND INTERFERENCES 

To the best of Appellants' knowledge, no pending appeals or interferences 
directly affect or are directly affected by the decision of this Appeal by the Board. 

STATUS OF THE CLAIMS 

The application of this invention was filed with 64 claims. In a telephone 
conversation on 8 November 2001, Appellants elected to prosecute claims 1-16 
and 33-48. Claims 17-32 and 49-64 were removed from consideration. Therefore, 
Claims 1-16 and 33-48 remain pending. 

STATUS OF AMENDMENTS 

There were no amendments filed subsequent to the final rejection. 
Therefore, there are no amendments pending in this Application. 

SUMMARY OF THE INVENTION 

The present invention receives data read by a bar code reader. The data 
received from the bar code reader and an identification of the bar code reader is 
stored in-a data entity. The data entity is a data object that is then passed to a 
software application. The identification then is used to associate the data in the 
data entity with an expected input of the software application. 
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More specifically, this invention provides a manner of receiving data from 
a bar code reader. (Page 10, lines 2-10) The received data is then stored in an 
entity related to the bar code reader. (Page 11, line 19- page 12, line 12). This data 
entity is a data object. The data in the object may be processed into a common 
format. (Page 12, line 4) 

An identification of the bar code reader is then also stored in the entity. 
The entity is then transferred to a software application. (Page 20, lines 8-14). The 
identity information of the device in the entity is then used to associate the entity 
with a data field in the software application. Page 21, lines 9-16) The identity 
information may include information about time, position, temperature, humidity 
and past data flow through the system. 

The software application may include one or more forms that receive data 
from one or more form objects. (Page 11, lines 12-18). The form objects include 
data selection criteria. The selection criteria may include information such as 
content of the data, format of the data, and identification information of the bar 
code reader. The data selection criteria in of the forms in the software application 
and the identity in the data object storing the input data from the bar code reader. 
(Page 18, lines6-15) Each of the forms may be associated with one or more input 
requestors in the software application. (Page 13, lines 1-6). The forms may be 
controlled by form objects. Processing details of the data objects are not known to 
the form objects. 




Docket No.: SYM-0625 



The transferring of the data may be performed by a data exchange 
mechanism. The data exchange mechanism may be provided by a dynamic data 
exchange, a component object model, object linking and embedding, a distributed 
component object model, or a common object broker remote access. 

ISSUES 

In the office Action dated 16 July 2002, the Examiner rejects claims 1-36 
under 35 U.S.C. 103(a) as being unpatentable over U. S. Patent Number 5,119,479 
issued to Arai et al (Arai) in view of U.S. Patent Number 5,801,696 issued to 

Roberts et al. (Roberts). The Examiner also states the correction to the 
specification have not been made. 

Appellants assert that the Examiner has not satisfied the requirements for 
proving prima facie obviousness as required by case law and the MPEP. 
Specifically, Appellants assert that the Examiner has not provided a teaching of 
using a bar code reader. Appellants further assert that the Examiner has failed to 
provide a teaching of storing data received from a bar code reader in an entity. 
Further, even if the Examiner has found art that teaches all of the limitations of 
this invention, the Examiner has failed to provide evidence of a motivation to 
combine. 
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GROUPING OF THE CLAIMS 

Appellants hereby elect the following groups for purpose of this Appeal. 
Group I includes claims 1-16 and Group II includes claims 33-48. Group I 
includes an independent method claim, claim 1, and claims dependent from claim 
1. Therefore, if claim 1 is allowable, claims 2-16 in Group I are likewise 
allowable. Group II includes an independent claim, claim 33, to a computer 
system and dependent claims 34-48. Therefore, if claim 33 is allowable, all claims 
of group II are allowable. 



ARGUMENT 

35 U.S.C. § 103(a) Rejection 



Requirements for Proving Prima Facie Obviousness 

Case law and the MPEP require three basic criteria must be met To 
establish a prima facie case of obviousness in a rejection. The first criteria is that 
the rejection must include a suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the references or to combine reference teachings. The second 
criteria is that the combination must have a reasonable expectation of success. 
Finally, the third criteria requires that the prior art references must teach or suggest 
all the claim limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in the 
prior art, not in appellants' disclosure. In re Vaeck, 20 USPQ2d 1438 (Fed. Cir. 
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1991). It is the burden of the Examiner to establish prima facie evidence that thee 
three criteria are met by a rejection. See MPEP § 2142. 

In this application, the Appellants contend that the Examiner has failed to 
establish prima facie obviousness of the claims. Specifically, Appellants assert 
that the examiner has not taught storing data in a data entity and has not taught 
receiving the data from a bar code reader. Furthermore, even if all of the elements 
are taught by the art cited in the rejection, the Examiner has not provided a 
sufficient motivation or suggestion to combine the references. 

Teaching of All Claim Limitations 

The Examiner must present art that teaches or suggests all of the claimed 
elements of a claim in order to prove prima facie obviousness of the claim. In re 
Royka 490 F.2d 981, 180 USPQ 580 (CCPA 1974). See also, MPEP § 2143.03. 

No teaching of storing data from a bar code reader in an entity 

Claim 1 recites storing input data from a bar code reader in a data entity and 
storing identification information of the bar code reader in the data entity. The 
data entity is then transferred to the software application. As described in the 
specification, the data entity is a data structure in which the data is stored and 
passed to the software application. The data entity is an object or data class in an 
object oriented programming language. The use of an object or data class as an 
entity allows a programmer to easily configure and change a system since the 
workings of the object in manipulating the data do not need to be known to the 
programmer. 
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Arai does not teach the storing of the data in an entity or a data structure. 
Aria teaches a system for providing a rule based system that using a name 
associated with an input device for determining the use of data receive from a 
device by an application. See Abstract. In Aria, there is no mention of storing of 
the data in an entity and then transferring the entity to the application. In Arai, 
data is received from a device in a logical switching device. (See Col. 5, lines 10- 
16). The logical switching device then associates a name, stored in a- table, with 
the data. (See col. 5, lines 11-12). The data us then passed to a UI execution 
device. (Col. 5, lines 17-19). The UI execution device identifies the name 
associated with the data. (Col. 5, lines 17-19). The rules for the name are then 
retrieved from a data store. (Col. 5, lines 19-25). The data store stores rules for 
operations to be performed on the data based upon each name. (Col. 5, lines 21- 
25). The operations for the particular name are then applied to the data to provide 
a control output. (Col. 5, lines 25-27). There is no mention in Arai of storing the 
data received in an entity. In fact there is no mention at all in the Arai reference 
that provides a data structure that is passed between software application. Arai 
merely teaches the type of data being transmitted. 

In the office action, the Examiner states a data entity is taught in Col. 6, 
lines 18-29. In Col. 6, lines 18-23, the locking of a name to associate with data 
from a device is taught. The data transmitted to the UI execution in Arai is taught 
to have the form shown in Figure 7 and includes an input device name, an input 
operation name, cursor coordinates and a character. (See Col. 6 lines 24-29). 
There is no mention in Arai that the data is transmitted in a particular data 
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structure. The data transmitted only contains the information described. There is 
no teaching that the data is stored in any type of data structure or transmitted in 
any type of data structure. 

For these reasons, the Appellants believe that the Examiner has failed to 
provide a teaching of the limitation of storing the data from a bar code reader in an 
entity. Therefore, a prima facie showing of obviousness has not been made with 
regards to claim 1. Thus, the rejection to claim 1 must be removed. 

If an independent claim is non-obvious under 35 U.S.C. § 103, then any 
claim depending from the independent claim is non-obvious. In re Fine 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988). See also MPEP § 2143.03. Claims 2-16 
are dependent from claim 1. Therefore, claims 2-16 are also allowable and the 
rejection to these claims must be removed. 

Claim 33 recites a computer which includes a memory writer that stores 
data received from a bar code reader and an identity of the bar code reader in a 
data entity, a send that transmits the entity to a software application, and a matcher 
that associates the data entity with a data field. The Examiner states that Arai 
teaches the storing of data received from a bar code reader and an identity of the 
bar code reader in a data entity. 

Arai does not teach the storing of the data and identity in an entity or a data 
structure by a memory writer. Aria teaches a system for providing a rule based 
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system that using a name associated with an input device for determining the use 
of data receive from a device by an application. See Abstract. In Aria, there is no 
mention of storing of the data in an entity by a memory writer and then 
transferring the entity to a software application by a sender. In Arai, data is 
received from a device in a logical switching device. (See Col. 5, lines 10-16) The 
logical switching device then associates a name, stored in a table, with the data. 
(See col. 5, lines 1 1-12) The data us then passed to a UI execution device. (Col. 5, 
lines 17-19) The UI execution device identifies the name associated with the data. 
(Col. 5, lines 17-19) The rules for the name are then retrieved from a data store. 
(Col. 5, lines 19-25) The data store stores rules for operations to be performed on 
the data based upon each name. (Col. 5, lines 21-25) The operations for the 
particular name are then applied to the data to provide a control output. (Col. 5, 
lines 25-27). There is no mention in Arai of storing the data received in an entity 
by a memory writer. In fact there is no mention at all in the Arai reference that 
provides a data structure or data entity that is passed between software application. 
Arai merely teaches the type of data being transmitted. 

In the office action, the Examiner states a data entity is taught in Col. 6, 
lines 18-29. In Col. 6, lines 18-23, the locking of a name to associate with data 
from a device is taught. The data transmitted to the UI execution in Arai is taught 
to have the form shown in Figure 7 and includes an input device name, an input 
operation name, cursor coordinates and a character. (See Col. 6 lines 24-29) There 
is no mention in Arai that the data is transmitted in a particular data structure. The 
data transmitted only contains the information described. There is no teaching that 
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is no mention in Arai that the data is transmitted in a particular data structure. The 
data transmitted only contains the information described. There is no teaching that 
the data is stored in any type of data structure or transmitted in any type of data 
structure. 

For these reasons, the Appellants believe that the Examiner has failed to 
provide a teaching of the limitation of a memory writer that stores the data from a 
bar code reader and the identity of a bar code reader in a data entity. Therefore, a 
prima facie showing of obviousness has not been made with regards to claim 33. 
Thus, the rejection to claim33 must be removed. 

If an independent claim is non-obvious under 35 U.S.C. § 103, then any 
claim depending from the independent claim is non-obvious. In re Fine 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988). See also MPEP § 2143.03. Claims 34- 48 
are dependent upon amended claim 33. Therefore, claims 34-48 are allowable for 
at least the same reasons as amended claim 33. Other arguments as to the 
allowability of claims 34-48 are moot and omitted for brevity. For these reasons, 
Appellants request claims 34-48 be allowed. 

No Teaching of a Bar Code Reader 

Claim 1 is directed to storing data received from a bar code reader and an 
identity of a bar code reader in a data entity. Arai does not teach using the 
disclosed rule based system with a bar code reader. Arai states that the taught 
system may be used with a keyboard or other input device such as a mouse. (See 
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provide a bar code reader. However, Roberts does not specifically teach a bar code 
reader. Instead, Roberts teaches a keyboard like device. (See Col. 5, line 50). 

In Roberts, a "keyboard like device" is defined as a device that sends a 
stream of characters input into the system. (Col. 5, line 51). Examples of 
keyboard like devices include keyboards and a speech recognition device that may 
turn spoken words into sequences of keystrokes. (Col. 5 lines 52-54) For each 
"keyboard-like device" a queue handles the keystrokes in a FIFO manner. (See 
Col. 5, lines 55-58). A stream is a continuous input of data of indefinite length. 
For example, streaming data over the Internet means the continuous transfer of 
data of an undetermined length over time. From the example and the description, 
it is obvious that a keyboard like device is a device that provides keystrokes 
identifying characters over time and that the length of the stream of characters 
received is indefinite. The FIFO is needed to ensure that all of the characters input 
are received and processed. Further, a human user inputs the data with the 
"keyboard-like" device using either typed keystrokes or spoken words. 

A bar code reader, on the other hand, does not receive a stream of data. 
Instead, a bar code reader scans a bar code and converts the code to a string of 
alphanumeric characters. Every input from a bar code reader will be a string of 
characters of a certain, predetermined length. Therefore, the FIFO buffer and 
other circuitry that is taught to ensure capturing all of the input data is not needed 
to receive and handle the characters from the bar code reader. Furthermore, no 
human interaction is needed to provide the input from a bar code reader. Many 



11 



Docket No.: SYM-0625 

bar code readers are used in conveyor and other automated systems to identify 
objects passing the bar code reader. One skilled in the art would recognize that 
different circuitry and programming would be needed to receive data from a 
"keyboard-like device' 1 described by Roberts and a bar code reader. Thus Roberts 
does not teach a bar code reader as claimed in claim 1. Therefore, the Examiner 
has failed to teach storing data received from a bar code reader and the rejection to 
claim 1 must be removed. 

If an independent claim is non-obvious under 35 U.S.C. § 103, then any 
claim depending from the independent claim is non-obvious. In re Fine 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988). See also MPEP § 2143.03. Claims 2-16 
are dependent from claim 1. Therefore, claims 2-16 are also allowable and the 
rejection to these claims must be removed. 

Claim 33 recites a memory writer that stores data received from a bar code 
reader in a data entity. Arai does not teach using the disclosed the rule based 
system with a bar code reader. Arai states that the taught system may be used with 
a keyboard or other input device such as a mouse. (See Col. 1, lines 15-22). To 
teach a bar code reader, the Examiner relies on Roberts to provide a bar code 
reader. However, Roberts does not specifically teach a bar code reader. Instead, 
Roberts teaches a keyboard like device. (See Col. 5, line 50). 

In Roberts, a "keyboard like device" is defined as a device that sends a 
stream of characters input into the system. (Col. 5, line 51). Examples of keyboard 
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like devices include keyboards and a speech recognition device that may turn 
spoken words into sequences of keystrokes. (Col. 5 lines 52-54) For each 
"keyboard-like device" a queue handles the keystrokes in a FIFO manner. (See 
Col. 5, lines 55-58). A stream is a continuous input of data of indefinite length. 
For example, streaming data over the Internet means the continuous transfer of 
data of an undetermined length over time. From the example and the description, it 
is obvious that a keyboard like device is a device that provides keystrokes 
identifying characters over time and that the length of the stream of characters 
received is indefinite. The FIFO is needed to ensure that all of the input characters 
are received and processed. Further, a human user inputs the data with the 
"keyboard-like" device using either typed keystrokes or spoken words. 

A bar code reader, on the other hand, does not receive a stream of data. 
Instead, a bar code reader scans a bar code and converts the code to a string of 
alphanumeric characters. Every input from a bar code reader will be a string of 
characters of a certain, predetermined length. Therefore, the FIFO buffer and 
other circuitry that is taught to ensure capturing all of the input data is not needed 
to receive and handle the characters from the bar code reader. Furthermore, no 
human interaction is needed to provide the input from a bar code reader. Many 
bar code readers are used in conveyor and other automated systems to identify 
objects passing the bar code reader. One skilled in the art would recognize that 
different circuitry and programming would be needed to receive data from a 
"keyboard-like device" described by Roberts and a bar code reader. Thus Roberts 
does not teach storing data from a bar code reader as claimed in claim 33. 
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Therefore, the Examiner has failed to teach a memory writer that stores data 
received from a bar code reader and the rejection to claim 33 must be removed. 

If an independent claim is non-obvious under 35 U.S.C. § 103, then any 
claim depending from the independent claim is non-obvious. In re Fine 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988). See also MPEP § 2143.03. Claims 34-48' 
are dependent upon amended claim 33. Therefore, claims 34-48 are allowable for 
at least the same reasons as amended claim 33. Other arguments as to the 
allowability of claims 34-48 are moot and omitted for brevity. For these reasons, 
Appellants request claims 34-48 be allowed. 

Lack of Motivation to combine 

Furthermore, even if the Examiner has provided teachings of every 
limitations of the claims in the rejections, the Examiner has failed to establish 
prima facie obviousness because the Examiner has failed to provide the criteria of 
a proper motivation or suggestion to combine the references. See In re Vaeck, 947 
F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). See also, MPEP §2143. 
Obviousness can only be established by combining or modifying the teaching of 
the prior art to produce the claimed invention where there is some teaching, 
suggestion or motivation to do so found either explicitly or implictly in the 
references themselves or in the knowledge generally available to one of ordinary 
skill in the art. See In re Kotzab, 217 F.3d 1365, 1370. See also MPEP § 2143.01. 
This teaching or suggestion to make the combination and a reasonable expectation 
of success, must both be found in the prior art and not in the appellants' 
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disclosure. See In re VaecK 947 F.2d 488 (Fed. Cir. 1991). The Examiner has 
merely made an assertion of motivation or suggestion to combine the references in 
the rejections and has not provided evidence of a rationale to do so. 

In regards to the rejection of claim 1, the Examiner states that one skilled in 
the art would combine the references because Roberts recognized input from 
various peripheral devices may be handled through the same input event 
dispatching entity. Roberts does not teach input from various input devices may 
be handled by the same input event entity. Instead, Robert teaches that inputs 
devices may be categorized as either a pointing device or non-pointing device and 
input from these devices must be handled in different manners. (See Col. 5, line 
50- Col. 6, line 7). The input from "keyboard-like" devices and pointing device 
are handled differently in Roberts. This is a direct contradiction of the Examiner's 
assertion that Roberts teaches all input device may be handled by the same entity. 
One skilled in the art would conclude from reading Roberts that different device 
require different handling. Thus, there is no evidence of a motivation to combine 
the references and the rejection must be removed. 

If there is no motivation to combine the references for claim 1, there is no 
motivation to combine the references for claims 2-16. Thus, the rejections to 
claims 2-16 must be removed. 

The argument for lack of motivation or suggestion to combine the reference 
for claim 1 also applies to the rejection of claim 33. Thus, the rejection of claim 33 
must be removed for the same reason as the rejection to claim 1. 
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The argument for lack of motivation or suggestion to combine the reference 
for claim 1 also applies to the rejection of claim 33. Thus, the rejection of claim 33 
must be removed for the same reason as the rejection to claim 1. 

If there is no motivation or suggestion to combine the references for the 
rejection of claim 33, there is no motivation or suggestion to combine the 
references for the rejections of claims 34-48. Therefore, the rejections to claims 
34-48 must be removed. 

Conclusion 

For the above reasons, Appellants believe the Examiner has not provided 
evidence of prima facie obviousness of claims 1-16 and 33-48. Therefore, 
Appellants respectfully request that the Board remove the rejections of all claims 
and allow this case. 



Respectfully submitted, 
Sierra Patent Group, Ltd. 



Sierra Patent Group, Ltd. 
P.O. Box 6149 
Stateline, NV 89449 
(775) 586-9500 



Dated: December 18, 2002 




Reg. No. 43,265 
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1. A method for transferring data from a bar code reader to a software 
application having one or more data field, including the steps of: 

storing data from a bar code reader in an entity; 

storing identification information regarding the bar code reader of 
the data in said entity; 

transferring said entity to the software application; and 

associating said entity with a data field in the software application 
based on said identification information. 

2. The method of claim 1, further including the step of: 
forming a data object from said entity. 

3. The method of claim 2 wherein the software application includes 
one or more forms, each of said forms designed to receive one or more form 
objects, each of said form objects containing a data selection criteria. 

4. The method of claim 3, wherein said transferring step includes the 
step of: 

routing said data object to one of said form objects, said form object 
chosen based on said data selection criteria and said identification information. 
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5. The method of claim 3, wherein said form objects associated with a 
specific form collectively describe the data input requirements for said form. 

6. The method of claim 1, wherein said identification information 
includes information chosen from the group consisting of time, position, 
temperature, humidity, and indications of the past history of data flow through the 
system. 

7. The method of claim 3, wherein the software application further 
includes one or more input requestors, each of said forms associated with one of 
said input requestors. 

8. The method of claim 3, wherein said selection criteria specifies 
conditions for using said data object to satisfy the input requirements of one of 
said form objects. 

9. The method of claim 3, wherein said selection criteria is based on 
information chosen from the group consisting of the content of the data, the format 
of the data, and said identification information. 

10. The method of claim 3, further including the step of processing the 
data in said data object. 
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11. The method of claim 10, wherein the processing details of said data 
object are not known the form object. 

12. The method of claim 1, wherein said transferring step is performed 
by an operating system. 

13. The method of claim 1, wherein said transferring step further 
includes the step of: 

sending the data to a data exchange mechanism. 

14. The method of claim 13, wherein said data exchange mechanism is 
chosen from a set consisting of a dynamic Data exchange (DDE), a component 
object model (COM), an object linking and embedding (OLE), a distributed 
component object model (DCOM) and a common object broker remote access 
(COBRA). 

15. The method of claim 1, wherein said transferring step includes 
operations chosen from the group consisting of operation sequencing, data 
translation, process synchronization, content filtering, and path routing. 

16. The method of claim 1 wherein said transferring step is 
accomplished using component objects. 
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33. A computer system for transferring data from a bar code reader to a 
software application having one or more data fields, including: 

a memory writer which stores the data from the bar code reader in an 
entity and stores identification information regarding the bar code reader of the 
data in said entity; 

a sender which transfers said entity to the software application; and 
a matcher which associates said entity with a data field in the 
software application based on said identification information. 

34. The computer system of claim 33 further including: 

an entity modifier which forms a data object of said entity. 

35. The computer system of claim 33, wherein the software application 
further includes one or more forms, each of said forms designed to receive one or 
more form objects containing a data selection criteria. 

36. The computer system of claim 35, wherein said sender includes: 

a router which routes said data object to one of said form objects, 
said form object chosen based on said data selection criteria and said identification 
information. 

37. The computer system of claim 35, wherein said form objects 
associated with a specific form collectively describe the data input requirements of 
said form. 
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38. The computer system of claim 33, wherein said identification 
information includes information chosen from the group consisting of time, 
position, temperature, humidity, and indications of past history of data flow 
through the system. 

39. The computer system of claim 35, wherein the software application 
further includes one or more input requestors, each of said form objects associated 
with one of said input requestors. 

40. The computer system of claim 35, wherein said selection criteria 
specifies conditions for using said data object to satisfy the input requirements of 
one of said form objects. 

41. The computer system of claim 35, wherein said selection criteria is 
based on information chosen from the group consisting of the content of the data, 
the format of the data, and said identification information. 

42. The computer system of claim 35, further including a processor 
which processes the data in said data object. 

43. The computer system of claim 42, wherein the processing details of 
said data object are not known to said form object. 
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44. The computer system of claim 33, wherein said sender is contained 
within an operating system. 

45. The computer system of claim 33, wherein said sender is contained 
within an operating system. 

46. The computer system of claim 45, wherein said data exchange 
mechanism is chosen from the set consisting of a dynamic data exchange (DDE), a 
component object model (COM), object linking and embedding (OLE), a 
distributed component object model (DCOM), and a common object broker 
remote access (COBRA). 

47. The computer system of claim 33, wherein said sender includes: 

a sender which performs operations chosen from the group 
consisting of operation sequencing, data translation, process synchronization, 
content filtering, and path routing. 

48. The computer system of claim 33, wherein said sender includes: 

a sender which transfers said entity to the software application using 
component objects. 
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